A new approach to the design of distributed operating systems

Application Model Computational Reality Mapping implementation must be tailorable. For example, a reference which crosses a machine boundary may use a name server but when its target is on the local machine, it should be possible to use a simple pointer. A Framework for Mapping π π defines a uniform object model for both application and system software. Its architecture is based on three main notions: Resources elements of the computational reality. Events the causalities of computation. Interfaces structured presentation of resources and events. π specifies how these three ideas are combined into a flexible object-based framework. The elements of the computational reality, such as the computational, storage and communication resources, are encapsulated into resource objects. Similarly, abstract resources like locks and messages are also presented as resource objects. A programmer can use these objects in various ways. They can be used as is, or several can be combined or additional services can be defined. Events are typed entities which encapsulate important state changes in the system. They have three aspects: generation, notification and handling. Each object clearly specifies the events that it might generate and the events that it can handle. Notification mechanism allows decoupling of event generation and event handling. Applications see resource objects and events through interfaces. The interfaces contain the type specification for the services provided by the object and also for the events generated by the object. These three components are glued together by the π environment. The environment provides services traditionally found in operating systems, language tools and run-time support systems. It is not a rigid structure and applications can alter it by incorporating value-added services. The generalized object model gives the environment flexibility in the resolution of activation targets. Reification of otherwise implicit features supports metacomputation which allows modifications to the environment. Finally, version set interfaces streamline the management of changes caused by metacomputation. The changes are propagated by metaobjects to their acquaintances, thereby providing a lazy propagation mechanism suitable for distributed systems. The flexible features can be illustrated with a sequence of distributed shared data abstractions. At the basic level, the distributed shared data appears to a programmer like a normal region of memory. Any support for distribution, such as replication and coherency control, is invisible. Similarly, any associated metadata, such as type information for translation between architectures, would be hidden. The abstraction is refined if the metadata is reified and made available for modification. A further refinement is to make the application aware that the data is virtually shared through coherent replicas. Finally, the coherency manager itself could be reified to allow the programmer to change the coherency policy to improve performance. Goals The long term goal of the π project is to develop a framework within which operating systems can be assembled using basic components and their refinements. It focuses on change as the most important aspect and handles it through metacomputation and interfaces. π: A New Approach to the Design of Distributed Operating Systems Dinesh C. Kulkarni, Arindam Banerji and David L. Cohn Distributed Computing Research Laboratory Computer Science & Engineering University of Notre Dame Notre Dame, IN 46556 USA Contact: [email protected] Abstract Operating systems need to be flexible to meet diverse application needs and to exploit continuously evolving hardware technology. They must present an application-oriented view for ease of use and handle resources effectively for efficiency. Applications can be modeled as dynamic directed graphs that the system software maps onto resources. Events, which generalize method invocations, interrupts and exceptions, contribute to the dynamic nature of the graph. A new operating system architecture, called π is proposed to achieve a flexible mapping. Using the architecture, operating system components can be tailored for specific applications and various hardware platforms. The π architecture specifies consistent service interfaces while metacomputing allows changes to service set implementations and the service set itself.Operating systems need to be flexible to meet diverse application needs and to exploit continuously evolving hardware technology. They must present an application-oriented view for ease of use and handle resources effectively for efficiency. Applications can be modeled as dynamic directed graphs that the system software maps onto resources. Events, which generalize method invocations, interrupts and exceptions, contribute to the dynamic nature of the graph. A new operating system architecture, called π is proposed to achieve a flexible mapping. Using the architecture, operating system components can be tailored for specific applications and various hardware platforms. The π architecture specifies consistent service interfaces while metacomputing allows changes to service set implementations and the service set itself. 1. A VISION OF THE FUTURE OF COMPUTING As the number of computing systems continues to explode, the number of computing architectures does not. The number of computers now is an order of magnitude than a decade ago, but there are probably fewer architectures. Therefore, successful architectures, both for hardware and software, must be flexible enough to span a broad range of uses. The same processor that is the heart of a super computer may also run a toaster. Hardware designers have long recognized the need to specify an architecture and then build a family of realizations. System software developers are just beginning to grapple with the same challenge. 1.1 Flexibility in Operating Systems The implications of flexibility in hardware design are clear: it must be possible to do the "same thing" across a broad cost spectrum. Flexibility was at the heart of IBM’s System/360 and many other systems. The implications of flexibility for operating systems is more complex. There is no one-dimensional measure, such as manufacturing cost, that defines a spectrum. Instead, operating systems must cope with a variety of application requirements and hardware configurations. The ability of an operating system architecture to optimize in these situations is a measure of its flexibility. Different classes of applications have different needs. No single set of primitives will satisfy them all and no single implementation will be best in all cases. For example, when data is shared between remote elements of an application, one of several coherency control mechanisms could be used. The best choice depends on how the application uses the data. However, an application may use the same data differently at different times and hence want to dynamically alter coherency control. A flexible operating system architecture must accommodate a wide range of hardware structures. Classically, this means various processor speeds, differing memory and disk sizes and sundry peripheral devices. Today it would also include multiprocessor systems, diverse network topologies and a new types of input/output media. In the future, as radiobased networking becomes common, these changes will be dynamic, requiring the operating system to adapt as elements of the system move into and out of range. 1.2 Constraints and Conditions A major goal of all system software is to relieve the programmer from the burden of solving non-application domain problems. The sequence of tools from programming languages through run-time support to operating systems must make it easy for the programmer to express what is to be done and then to do it. For simplicity, this discussion will combine run-time support, which is normally associated with a particular language, with operating systems, which are more generic. There is no clear distinction between them and a good operating system architecture should be able to offer whatever run-time tools a language needs. Indeed, one measure of an operating system’s flexibility is whether it can provide those tools. A flexible operating system should scale. That is, the same software architecture should be effective in embedded processors and in large main-frames. This does not mean that one